Micro-services include a software architectural style of modular processes for complex applications. Micro-services architectures involve a modular approach to adding new features that groups related functions or groups by resource, allowing maximum efficiency in hyper scale due to separation of processes based on consumption of storage, input/output (I/O), memory and CPU resources. A single application is broken into a suite of smaller services, each running in its own process and communicating with lightweight mechanisms, often a Hypertext Transfer Protocol (HTTP) resource application programming interface (API). The services are grouped around business capabilities or functions and independently deployable by fully automated deployment machinery. Each set of services can employ different data storage technologies.
Network applications for micro-services, such as webscale applications, often face implementation difficulties. Webscale applications possess the ability to scale elastically with demand, even if the demand is far beyond the initial forecast by seamlessly adding memory, compute, storage, and networking resources without impacting the availability of the service or services. Webscale applications are currently implemented with distributed application models or similar modularized technologies, such as virtualization and Linux containers. Webscale applications require application aware sessions (and/or flow anchoring) based on load, mobility of the session (or flow), flow load-balancing, consolidation for shared memory, and hyper performance and scale, such as a No structured query language (NoSQL) non-relational databases. Webscale databases are designed with anticipation of data loss and administrators/database designers may weigh orders of magnitude performance gains (speed, volume, concurrency, non-transformation, etc.) over per-transaction latency and guaranteed transactions.
Current solutions for resilience may experience different issues in execution. Non-stop routing (NSR) paradigms in webscale architectures require the transmission control protocol (TCP) state (current window/sequence number) to be conveyed in instances in which a Border Gateway Protocol (BGP)/TCP session is moved. Each time a new feature is enabled, awareness of the features needs to be built into state synchronization mechanisms and this often leads to lagging of features. Other mechanisms may produce different issues, such as graceful restart (GR) in which true failures are required to wait for the GR timeout period before declaring a session down. Additionally, although many systems use proprietary schemes to load-balance routers within their own chassis or multi-chassis, there are currently no load-balancing mechanisms for network applications today across data centers.